Skip to content

Conversation

cgwalters
Copy link
Collaborator

I think a good pattern is to keep an open (draft) pull request that should fail CI, and verify that it actually does.

It's surprisingly easily to e.g. have CI not actually test the code. In this case we have our "reverse dependency testing" which patches the crate to use the local code, and that could easily not work.

I think a good pattern is to keep an open (draft) pull request
that *should* fail CI, and verify that it actually does.

It's surprisingly easily to e.g. have CI not actually test the
code.  In this case we have our "reverse dependency testing"
which patches the crate to use the local code, and that could
easily not work.
@cgwalters
Copy link
Collaborator Author

Heh well, due to the semantics of where I chose to inject an error, it turns out this causes us to hang indefinitely...which is definitely a bug.

@cgwalters
Copy link
Collaborator Author

---- test_container_var_content stdout ----
thread 'test_container_var_content' panicked at 'called `Result::unwrap()` on an `Err` value: Exporting container

Caused by:
    0: exporting
    1: Fetching manifest
    2: synthetic CI failure', lib/tests/it/main.rs:897:67
stack backtrace:

Success!

@cgwalters cgwalters changed the title Test that CI successfully fails [DNM] Test that CI successfully fails Nov 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant